1. 前言：那個「不愛問問題」的新同事

想像你今天交辦一項任務給新同事：「幫我把這疊信件分類一下。」

如果這位同事是人類，他通常會回頭問你十個問題：要分哪幾類？標準是什麼？如果不確定要分哪一類該怎麼辦？但如果你把這句話交給 AI，它通常一個問題都不問，直接開始「腦補」——它會幫你自創類別、每次輸出的格式都不一，甚至還會順手幫你判斷一些你根本沒要求的細節，比如客訴成不成立。

AI 任務與傳統系統最大的不同，在於**「輸出的不確定性」**。傳統系統同樣的輸入永遠會得到同樣的輸出；但 AI 不是。作為 AI 產品架構師，我們必須體認到：AI 規格的核心目標不是定義邏輯，而是透過結構化規格，將不確定性「關進籠子裡」。

2. 重點一：AI 規格的本質——為不確定性打造一個「籠子」

在進入規格撰寫前，必須建立一個核心共識：「沒有分層（邊界表），就沒有規格」。一個成熟的 AI 任務規格必須引用邊界表的場景與版本，確保任務範疇已經過定義。

為了徹底控管 AI 的輸出，一個完整的 AI 任務規格應由以下 9 個核心區塊組成：

1. 任務識別 (Task ID)：引用邊界表場景與版本，確保任務合法。
2. 輸入 (Input)：定義來源資料與格式。
3. 輸出 (Output)：定義欄位、型別與列舉值。
4. 處理規則 (Rules)：模型決策的邏輯指引。
5. 限制禁止 (Prohibitions)：明確定義 AI 絕對不能做的事。
6. 例外處理 (Exceptions)：定義異常情境的路徑與原因碼。
7. 驗收標準 (Acceptance)：可量測的品質與紅線指標。
8. 治理欄位 (Governance)：包含模型版本、選用理由與運作摘要。
9. 版本紀錄 (Version History)：追蹤規格的演進。

針對 AI 的特性，規格設計的核心心法是：

> 「格式零容忍、紅線零容忍、品質給區間。」

3. 重點二：拒絕格式漂移與範圍蔓延

沒有規格的 AI 任務，通常會面臨兩種災難性的下場：

• 下場一：格式漂移 (Format Drift) 今天 AI 輸出的分類叫「保單行政」，明天變成「保單相關事務」，後天又自創了「其他行政類」。這會直接導致下游程式崩潰。解決方案是在輸出區塊強制使用 enum（封閉列舉）。我們必須鎖死類別，模型不得自創任何值。記住：「品質可以商量，格式不行。」
• 下場二：範圍蔓延 (Range Creep) 需求只說「分類」，AI 卻順便給了處理建議。使用者若開始依賴這些未經核准的建議，AI 就實質上接管了決策權。這就是為什麼規格中必須包含「限制禁止」區塊，明確阻斷 AI 的權力越界。

4. 重點三：例外處理與治理欄位——讓「問責」落地

在 AI 規格中，例外處理不是選配，而是與下游自動化銜接的關鍵。我們必須定義明確的原因碼 (Reason Codes)，例如：

• E1 無法分類：將案件導回人工審核。
• E2 敏感資訊：觸發安全中斷流程。
• E3 格式損壞：觸發重試或報錯機制。

這些原因碼不只是為了偵錯，更是為了讓下游系統能根據不同代碼執行自動化工作流。

此外，為了符合監管要求與自律規範，規格中必須內建**「治理欄位」。其中最重要的是「模型運作方式摘要」**——這必須是一段讓業務負責人（Business Owner）三句話就能讀懂的文字。如果負責人看不懂 AI 怎麼運作，那所謂的簽核與「問責」就只是空話，會陷入「黑盒治理」的風險。

5. 重點四：別再寫「精簡、準確」！驗收標準的三原則

許多 PM 習慣用營運單位的語言寫標準（如：分類需準確），但模糊的標準會導致驗收權力移轉到「人」身上，引發專案信任危機。

驗收標準對比分析

撰寫三原則

1. 可量測：必須有明確數字門檻（如 ≥80%）。
2. 可自動檢核優先：利用程式比對實體，減少人工抽核負擔。
3. 紅線零容忍：涉及「不對稱風險」的事項必須是 0。例如 A4 標準：「急迫度『高』誤判為『低』」。為什麼要單獨列出？因為高判低的代價遠高於低判高，這類嚴重誤判必須列為 0 容忍紅線，不能被「整體準確率」給稀釋掉。

6. 實戰範例：公用信箱需求分類 v0.1

以下展示「公用信箱需求分類」示範規格的核心內容。

輸出欄位設計（區塊 3）

驗收標準目標值（區塊 7）

7. 結語：從「說人話」到「下指令」的思維轉變

從邊界表的分層定義，到將需求拆解成 9 個規格區塊，這不僅是技術文件的演進，更是一次思維轉變。在 AI 時代，產品經理與架構師不能只會「說人話」，更要學會透過結構化的框架來「定規則」。

規格模板的核心價值，在於讓 AI 的能力在已知的範圍內發揮，並在不可控的時刻具備自覺退出的能力。當 AI 成為你的下屬，你準備好成為那個定義規則、而不是只會下模糊指令的領導者了嗎？